The present invention relates to methods and apparatus for accelerating communication processes in industrial controls and more specifically to methods and apparatus for substantially reducing the time required to process common industrial protocol (CIP) network communications in motion control applications.
Industrial programmable logic controllers (PLCs) are special purpose processing devices used for controlling/monitoring automated and semi-automated industrial processes, machines, manufacturing equipment, plants, and the like. A typical PLC executes a control program or routine in order to track process variables or inputs representative of the status of controlled processes/machines and to generate outputs for controlling the processes/machines.
In distributed control systems, the process control tasks are distributed among several different controllers/processors, each of which performs different control functions. For instance many control systems include one or more main PLCs and distributed device processors where, as the label implies, individual device control and monitoring is accomplished using the distributed device processors and overall system control and coordination is handled by the PLCs. Thus, for example, a complex control system may include one or more PLCs and several hundred device processors linked to the PLCs via a communication network. An exemplary device processor may include a controller for a motor drive that runs complex control algorithms to control motor speed, acceleration, deceleration, torque and so on as a function of various motor and other operating parameters monitored by the device processor directly and/or parameters associated with other motors or sensors at other system stations.
Various communication protocols have been developed to facilitate communication between remotely located network devices (e.g., PLCs, distributed device processors, and the like). For instance, IEEE 802.3 Ethernet is traditionally an office networking protocol that has gained universal acceptance world-wide. Ethernet is an open standard supported by many manufacturers and its infrastructure equipment is widely available and largely installed. Likewise, Ethernet's Transmission Control Protocol and Internet Protocol (TCP/IP) is ubiquitous as TCP/IP comprises the basic transport and network layer protocol of the internet that commonly links all Ethernet installations world-wide. The primary function of TCP is to allow blocks of binary data to be exchanged between computers and to ensure that all packets of data transmitted are received correctly, while IP makes sure that messages/data packets are correctly addressed and routed. Thus, TCP/IP does not define what the data means or how the data is to be interpreted. Instead, TCP/IP it is merely a transport and network protocol. User-Datagram Protocol/IP (UDP/IP) is another transport layer protocol that is responsible for ensuring prompt delivery of a data packet.
TCP/IP and UDP/IP are actually formed from suites of protocols upon which all internet communication is based. The suites of protocols are also referred to as protocol stacks and each data sending or receiving device (e.g., PLC, device processor, etc.) linked to internet must run separate protocol stacks. The use of the word stack refers to the simplified TCP/IP or UDP/IP layered reference model or stack that is used to design network software.
Each layer on a sending stack (i.e., a stack maintained by a device that sends a message on the network) communicates with the corresponding layer of the receiving stack (i.e., a stack maintained by a device that receives a message) through information stored in communication packet headers. As data is moved down the stack of the sending device, each stack layer adds its own header to the front of the message that it receives from the next higher layer. That is, the higher layers are encapsulated by the lower layers. Conversely, this header information is removed by the corresponding layer at the receiving device. In this way, the headers are essentially peeled off as the data packet moves up the stack of the receiving device to a receiver application.
For many years, the Common Industrial Protocol/Control and Information Protocol (CIP) has been widely used in industrial environments to provide both real-time and informational message functionality. Unlike TCP/IP and UDP/IP which are transport layer protocols, CIP is an application protocol and is essentially a messaging structure which defines rules for organizing and interpreting data. CIP is freely available, accessible to anyone, easy to understand and widely supported by many manufacturers of industrial equipment. For these reasons CIP has been used to building other industrial communication standards such as DeviceNet and ControlNet.
EtherNet/Industrial Protocol (EtherNet/IP) merges traditional IEEE 802.3 Ethernet with the CIP as its application layer to build a powerful industrial communication standard. EtherNet/IP shares the same physical and data link layers of traditional IEEE 802.3 Ethernet and uses the same TCP/IP and UDP/IP suites of protocols which makes EtherNet/IP fully compatible with existing Ethernet hardware, such as cables, connectors, network interface cards, hubs and switches. Since EtherNet/IP uses the same application layer protocol (i.e., CIP) used by both DeviceNet and ControlNet, EtherNet/IP, DeviceNet and ControlNet share common device profiles and object libraries which enables Ethernet, DeviceNet and ControlNet devices to communicate over the same network.
Thus, EtherNet/IP uses TCP/IP, UDP/IP, and Ethernet to carry the data of the CIP message structure between devices. That is, EtherNet/IP combines a physical network (Ethernet), with a networking standard (TCP/IP & UDP/IP) and a standard method of representing data (CIP).
Thus, in a distributed control system that includes a PLC and a distributed device processor where the PLC and device processor communicate using EtherNet/IP, when the PLC sends data (e.g., informational or control) to the device processor, the PLC packages the data into a CIP packet and passes the CIP packet down the PLC sender stack to generate an EtherNet/IP packet which is then transmitted to the device processor. When the device processor receives the EtherNet/IP packet, the device processor removes the header information to extract the CIP message and uses the CIP data in the device application. Similarly, when the device processor sends data to the PLC, the device processor packages the data into a CIP packet and passes the CIP packet down the distributed device sender stack to generate an EtherNet/IP packet which is then transmitted to the PLC which, upon receiving the EtherNet/IP packet, removes the header information to extract the CIP message.
In control applications generally and in motion control applications specifically, it is extremely important that control commands be distributed among distributed processors and PLCs extremely quickly to avoid uncontrolled system conditions. Here, the phrase “motion I/O connection processing time” is used to refer to the time required for a processor to receive an EtherNet/IP packet, remove packet headers to extract a CIP packet, extract data from the CIP packet, deliver the extracted data to an application, obtain data from the application, package the obtained data in a CIP packet, package the CIP packet in an EtherNet/IP packet, and transmit the EtherNet/IP packet onto the internet.
Currently motion control communications speed requirements leave about insufficient time for motion I/O connection processing (i.e., the time required to pack or unpack an EtherNet/IP-CIP packet) and this time will likely be reduced in the future as more stringent regulations are adopted by the industrial automation industry. While PLCs typically have plenty of processing power to handle communication tasks (i.e., packing and unpacking command data, informational data, etc.) within required processing times and still perform other required functions, unfortunately, tests have shown that distributed device processors that have to perform other control processes (e.g., motor control) often fail to meet the motion I/O connection processing time requirements.
One solution for dealing with distributed device processors that cannot meet motion I/O connection processing time requirements would be to redesign all device processors to have L2 cache which would remove the memory bottleneck and allow stack performance to be scaled directly with clock speed. This solution has several shortcomings. First, this solution would be particularly expensive as higher performance processors having L2 cache are generally more expensive than existing processors that have L1 cache. Additional overall system expense could render these types of systems unsuitable for certain applications.
Second, device processor suppliers may view EtherNet/IP as an evolving technology and not want to invest in developing new higher performing processors for an unproven market. This is especially true where suppliers will continue to have to provide current lower performing device processors for some time to support existing clients and systems and may not want to carry two different processors for different needs.
Third, this solution will likely be impractical for a long time as customers may perceive that current systems suffer in performance. To this end, where EtherNet/IP is used for motion control, all device processors that are to facilitate motion control within a system would have to be the high performance devices which means that every manufacturer that provides device processors that are used for motion control in the EtherNet/IP based system would have to provide the high speed processors. Here, where a particular manufacturer routinely purchases system components including device processors from four suppliers and one or more of the suppliers do not provide the higher performance processors, the manufacturer would likely perceive the EtherNet/IP based system as unsupported by the industry and could forego adoption thereof.
Thus, there is a need for systems and methods that allow EtherNet/IP to be used to communicate from a PLC to standard distributed device processors where motion I/O connection processing times meet short time requirements so that EtherNet/IP can be used effectively in motion control applications.